feat(setup): accept registry-url — the passthrough that kept every release workflow off this action - #54

Bumps the manifest and the pin in dep-check.yml together, which the release
gate requires -- 0.5.0 and 0.2.0 each published green while the pin stayed
behind, so no consumer received the change.

Carries the fix for usetheokit/theokit-sdk#569: floor legs whose dep this
workspace publishes are dropped, because pinning one installs its own tarball
beside the local copy (452 MB -> 4,432 MB peak, measured) and asks a question a
consumer never asks.

Eleven repositories consume this gate. Moving v1 is the separate step.

vitest-dev/vitest sets it repo-wide and documents ~15-20s per job -- the only
hard number anyone published for an install optimisation. Measured on
theokit-sdk, pnpm 10.34.1, two runs each against a warm store:

  default             2.78s, 2.54s
  TRUST_LOCKFILE      2.52s, 2.54s

Nothing. Their saving is real and ours is not, most plausibly because every job
here restores a warm store through the cache: pnpm above.

Recorded rather than left silent, following the precedent of the turbo-cache
note in theokit-sdk's ci.yml: configuration that does nothing is debt wearing an
optimisation's clothes, and the next person to read the vitest number should
find this instead of re-deriving it. It would have traded a supply-chain check
for zero measured seconds.

…kage

The leg builds every package that claims the floor. Doing it one --filter at a
time re-plans the task graph once per package and rebuilds the shared
dependencies each round.

Measured on theokit-plugins, whose leg claims 10 packages, cold cache (dist and
turbo cleared), two rounds each:

  loop (10 invocations)   35.2s, 39.6s
  batched (1 invocation)  23.4s, 24.0s

-34% and -39%, producing the same 10 dist/ directories and the same 20 build
successes.

Two things this deliberately does NOT do:

- batchedWithDeps returns null for npm and yarn rather than guessing. npm has no
  '...' equivalent at all, and yarn's 'yarn workspace <pkg> run' takes exactly
  one name -- batching there needs 'workspaces foreach', different semantics
  nobody here has measured. Those callers keep the loop, correct if slower.
- an empty package list returns null, because 'pnpm run build' with no filter
  builds the WHOLE workspace, which is the defect the per-package filter exists
  to prevent.

--package is now repeatable, and that needed parseArgs 'multiple: true'. Without
it the parser keeps only the LAST occurrence, so the repeated flag would have
silently built one package and reported the whole leg green -- caught by running
the command with three packages and reading the output, not by the tests.

Bumps to 0.10.0 with the workflow pin, together, as the release gate requires.

The obvious move is `cache: pnpm` on its Setup Node, and it would be dead
configuration. This job only runs when base_ref == 'main' -- a pull request,
never a push. A run restores a cache from its own branch or from the DEFAULT
branch, so a cache only ever written on release pull requests is one no other
run can reach: every leg a guaranteed miss, paying the save cost forever.

cloudflare/workers-sdk hit this exact shape and wrote it down: actions/cache
saves from a post step declaring post-if: success(), so a failing job never
saves either -- and this job has been failing.

What it was worth, measured on run 101194428887: install 26s and reinstall 10s
of a 319s run, about 8%. The two changes that matter took the other 92%.

Doing it properly needs cache/restore + explicit cache/save plus a job on
push: [main] to populate what the pull requests read. New machinery for 8%,
recorded rather than built.

…ecome one

Measured 2026-09-05 across the ten consumers: nine held byte-identical copies of
the 74-line gate and one held a variant that had learned two things the others
never received. A fix in one copy reached one repository.

The shared version is the union of both: the nine contributed the diagnostics
that cite git-safety.md and name the next step, theokit-sdk contributed
timeout-minutes and the changesets-bot exemption that cost #535 on 2026-09-03.

concurrency was deliberately not carried over, and the file says why, so its
absence does not read as an oversight.

actionlint and zizmor clean, both verified against a positive control.

…off this action

Measured 2026-09-05 across the ten consumers: 22 workflows set up Node and pnpm
by hand and exactly one file used this action. The largest group of duplicates is
the nine release.yml, and seven of them pass registry-url -- so adopting the
shared setup meant losing npm authentication.

Everything else was already equivalent, including the part most likely to be lost
in a hand rewrite: cache-dependency-path already lists package.json beside
pnpm-lock.yaml, which is the fix for a pnpm major bump restoring a store the new
pnpm reads as inconsistent.

The action's own CI job now runs it with a registry and asserts that setup-node
wrote an npmrc naming the registry and binding _authToken. It reads the file
rather than npm config get registry, which would go green on a registry that came
from somewhere else.

# Conflicts:
#	CHANGELOG.md